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FOREWORD 


This  document  was  prepared  in  close  coordination  with  the 
Fleet  Computer  Programming  Center,  Pacific,  as  part  of  a complete 
set  of  documentation  for  the  procurement  and  management  of  com- 
puter programs.  As  such  it  can  be  considered  an  Integrated  part 
of  a total  system  approach  to  computer  program  development  and 
procurement.  In  the  development  of  this  approach,  it  was  neces- 
sary to  prepare  each  package  incrementally.  Then  the  increments 
were  Integrated  into  the  whole  through  an  iterative  process. 

At  the  time  of  publication,  several  Iterations  have  been 
completed,  with  coordinated  inputs  from  all  known  sources.  However, 
the  process  of  updating  and  refining  this  document  should  be  a 
continuous  one  so  that  it  will  be  a viable  document  incorporating 
all  advances  and  evolutionary  changes  in  computer  programming. 

The  following  doc\aments,  of  which  this  is  one,  comprise  the 
system  documentation  package: 


Title 

Publication  No. 

A Preparation  Guide  for  Requests  for 
Quotation  for  Tactical  Data  System 
Computer  Programs 

414-04-1-689 

A Procurement  Specification  for  Tactical 
Data  System  Computer  Programs 

414-04-2-690 

A Guide  for  Preparation  of  Tactical  Data 
System  Operational  Specifications 

414-04-3-691 

Tactical  Data  System  Computer 

Programming  Specification 

4 14-04-4-692 

A Specification  for  Tactical  Data 

System  Computer  Program  Docum«^ntation 

414-04-5-693 

A Management  Manual  for  Tactical  Data 
System  Computer  Programs 

414-04-6-694 

m 


1.  GENERAL 

Tactical  Data  Systems  Operational  Specifications  will  be 
prepared  in  accordance  with  this  preparation  guide  and  in  response 
to  the  applicable  Technical  Development  Plan  (TDP)  and  its  enclosed 
Specific  Operational  Requirement  (SOR).  The  Operational  Specifica- 
tion and  the  applicable  equipment  description  are  the  two  basic 
guidance  documents  which  are  prepared  within  the  framework  of 
responsibility  of  the  TDS  Computer  Program  Manager.  These  docu- 
ments, Including  their  appendices,  provide  the  information  required 
(to  the  lowest  available  level  of  detail  that  is  meaningful)  for 
the  development  of  each  computer  program. 

Operational  Specifications  are  prepared  at  the  following  two 
levels  of  computer  programming  (see  Figure  1): 

(1)  Program  Level.  Defines  the  objectives  and  goals  of  the 
program,  establishes  the  overall  design  envelope,  inte- 
grates the  program  specification  with  other  TDS's;  and, 
above  all,  ensures  that  the  most  recent  inputs  from  the 
Fleet  are  considered. 

(2)  Module  Level . Individual  program  modules  (Including 

one  or  more  functions)  required  to  provide  an  overall  TDS 
program,  including  support  functions  (e.g.,  tracking, 
display,  executive,  etc.). 

At  the  program  level,  the  functional  interaction  with  the  user 
(Fleet)  and  other  tactical  data  systems  is  specified.  At  the 
module  level  the  interaction  between  the  program  level  and  the 
equipment  is  specified.  Although  the  two  levels  need  not  be 
prepared  by  the  same  activity,  close  coordination  is  Important. 

Both  levels  should  be  prepared  concurrently  to  ensure  that 
achievable  performance  is  consistent  with  user  requirements.  During 
the  early  stages  of  specification  preparation,  assumptions  concern- 
ing the  Fleet  requirements  and  the  equipment  capability  must  be 
clearly  stated.  In  making  assumptions,  uncertainties  should  be 
identified  and  classified  according  to  their  criticality. 
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OPERATIONAL  SPECIFICATION  STRUCTURE 


; j development  trends,  and  the  possibility  of  resolution  into  a 

' ‘‘  certainty.  Tables  1 and  2 are  included  as  examples  of  a means  for 

^ . readily  cataloging  assumptions  and  vincertaintles  in  the 

f 

i . specification. 


TABLE  1 

OPERATIONAL  SPECIFICATIO] 
ASSUMPTIONS  (EXAMPLE) 

Activity 

Program  Level 

Module  Level 

User  (Fleet) 

1 . Airborne 

2.  Surface 

3 . Ashore 

(List  all  assumptions) 

(List  assumptions) 

Equipment 

1 . Radar 

2 . Computer 

3 . Etc . 

(List  all  assumptions) 

(List  assumptions) 

OPERATIONAL  SPECIFICATION 
UNCERTAINTIES  (EXAMPLE) 
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2 . PURPOSE 

^ The  purpose  of  the  Operational  Specification  is  to  define 
precisely  the  operational  characteristics  of  a program  or  a module 
such  that ; 


The  fleet  user  understands  precisely  the  capabilities 
provided  by  the  computer  program  (acceptability  to  the 
user).  6—.^ 

Computer  programs  developed  from  the  specification  by 
different  contractors  result  in  identical  input  and  out- 
put interfaces  while  operating  under  the  same  criteria 
and  constraints .j;-;j(Compatlbility  in  system  operation  and 
equality  in  contractor  bidding.) 


(3)  All  information  (in  addition  to  the  Equipment  Description) 
which  is  required  for  completion  of  the  computer  program 
is  provided  in  the  basic  document  or  in  its  appendices. 
(Efficiency  in  program  development.) 
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3 . BACKGROUND 


The  purpose  of  the  Operational  Specification  has  rarely  been 
achieved  to  the  extent  desired  during  the  early  stages  of  acquisition 
of  TDS  computer  programs.  As  a result  of  this  lack  of  definition, 
the  following  has  occurred: 
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(1)  The  Fleet  user  has  not  become  aware  of  all  the  capabilities 
of  the  computer  program  until  a certain  amount  of  opera- 
tional experience  has  been  accrued, 

(2)  Computer  programming  contractors  have  had  incomplete  or 
erroneous  understanding  of  capabilities  required  of  the 
program. 


(3)  Lack  of  efficiency  has  occurred  in  the  development  of 

computer  programs  because  of  the  necessity  for  search  and 
study  of  many  documents  to  determine  the  required  func- 
tions, criteria,  and  constraints. 


4.  DISCUSSION 


The  development  of  sufficiently  definitive  Operational 
Specifications  is  necessarily  an  Iterative  process,  ftinctlonal 
descriptions  of  the  computer  program  produced  as  part  of  the 
development  of  each  program  provide  a useful  means  of  augmenting 
the  original  Operational  Specification.  Information  from  these 
functional  descriptions  may  be  extracted  and  modified,  if  appro- 
priate, and  used  to  modify  and  augment  the  basic  specification. 

The  process  of  successive  revision  of  the  Operational 
Specification  by  use  of  functional  descriptions  provides  progres- 
sively more  definitive  operational  specifications.  In  this  manner, 
both  government  and  contractor  personnel  achieve  an  increasingly 
clearer  vmderstandlng  of  the  program.  This  fact  is  of  great 
importance  in  computer  program  development,  particularly  when  per- 
sonnel changes  occur. 
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5. 


CONTENT  OF  THE  OPERATIONAL  SPECIFICATION 


5.1  General 

The  specification  should  contain  all  the  information  required 
to  prepare  a good  computer  program  logic  design.  The  Operational 
Specification  and  the  Equipment  Specifications  are  the  two  prime 
sources  of  characteristics  and  limitations  surrounding  the  program 
to  he  developed. 

Avoid  weak  Operational  Specifications  that  do  not  adequately 
define  the  complete  requirements  for  the  program.  If  the  Opera- 
tional Specifications  are  weak,  the  programmers  preparing  the 
program  may  constsintly  question  the  requirements  desired  but  not 
provided,  or  they  may  make  unwarranted  assumptions  rather  than 
call  the  programming  center  to  determine  limitations  and  specifica- 
tions of  the  program. 

The  content  of  all  Operational  Specifications  should  be  the 
same,  but  the  level  of  detail  is  a function  of  the  type  contract  to 
be  let.  For  example,  if  the  program  desired  is  a revision  of  the 
tracking  routine,  the  fixed  input  and  output  from  the  computer 
detector  and  Interceptor  programs  would  constrain  the  new  tracking 
program  to  enable  them  to  be  compatible.  Additionally,  the  revised 
tracking  programs  must  operate  within  the  time  constraints  allowed 
for  that  portion  of  the  program  associated  with  the  tracking  rou- 
tine and  must  use  the  existing  memory  allocations. 

In  contrast,  for  the  procurement  of  a new  program,  the 
constraints  are  limited  to  compatibility  between  input  words  from 
other  routines  and  the  output  words  to  other  routines  which  are 
also  subject  to  procurement.  When  a complete  procurement  is  antici- 
pated, it  is  not  very  Important  whether  new  or  old  routines  are 
modified,  so  long  as  the  words  are  compatible.  During  an  initial 
program  procurement  this  freedom  exists,  but  it  does  not  permit  the 
originator  of  an  Operational  Specification  to  Ignore  the  require- 
ment. The  requirements  for  word  compatibility,  memory  allocation, 
and  run  time  must  be  provided  in  the  Operational  Specification. 
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After  the  initial  procurement  is  completed,  the  word 
defintions  that  have  been  devised  by  the  programmers,  the  run 
times  experienced  during  the  program,  and  the  memory  allocations 
required  by  the  program  must  be  entered  in  the  Operational 
Specification  to  provide  a permanent  record  of  the  initial  pro- 
gram. These  data  may  be  used  as  a base  when  modifications  or 
revisions  to  the  routines  are  being  made. 

5.2  Operational  Specification 

A sample  table  of  contents  and  descriptions  of  the  require- 
ments for  each  of  the  sections  of  the  Operational  Specification 
follow. 
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SAMPLE 

TABLE  OF  CONTENTS 
FOR 

(NAME  OF  SYSTEM) 
OPERATIONAL  SPECIFICATION 


Page 


1.  PROGRAM  OPERATIONAL  SPECIFICATION  

1.1  User  Requirements  

1.2  Intersystem  Input  and  Output  

1.?  System  Operational  Constraints  

1.4  Assumptions  

1.5  Uncertainties  

2.  MODULE  OPERATIONAL  SPECIFICATIONS  

2.1  Problem  Statement  

2.2  Computer  and  Peripheral  Equipment 

Considerations  

2.2.1  Equipment  Description  

2.2.2  Executive  System  

2.2.3  Compiler  and  Language  

2.2.4  Summary  

2.3  Referenced  Dociunents 

2.4  Accuracies  

2.4.1  Input  Accuracy  Constraints  

2.4.2  Output  Accuracy  Constraints  

2.4.3  Required  Accuracies  of  the 

Computer  Program  

2.5  External  Error  

2.6  Word  Characteristics  

2.6.1  Input  Word  or  Switch  Characteristics  . . . 

2.6.2  Output  Word  or  Display 

Characteristics  

2.7  Memory  Requirements  

2.8  Program  Time  Allocations  

2.9  Specific  Requirements  

2.10  Testing  Requirements  
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1.  PROGRAM  LEVEL  OPERATIONAL  SPECIFICATION 

Include  a statement  that  this  specification  level  is  intended 
to  clarify  the  interfaces  between  the  user  (Fleet)  and  the  equip- 
ment in  terms  of  computer  program  routines. 

1.1  User  Requirements 

Specify  the  user  requirements  as  they  will  Influence  the 
computer  program.  Use  the  TDP,  SOR,  and  recent  inputs  from  the 
Fleet  as  a reference. 

1.2  Intersystem  Input  and  Output 

Specify  the  input  and  output  from  and  to  other  systems. 
Indicate  any  voids  and  uncertainties  that  must  be  clarified. 

1.5  System  Operational  Constraints 

Specify  any  system-level  operational  constraints  and  indicate 
the  type  encounter,  threat  size,  and  general  environment.  List  the 
constraints  by  priorities  desired. 

1.4  Assumptions 

List  all  the  assumptions  that  have  been  made  at  this  level 
and  indicate  when,  how,  and  by  whom  they  will  be  validated. 

1.5  Uncertainties 

Specify  all  uncertainties  that  will  influence  the  program. 
Indicate  (preferably  in  chart  form)  when,  how,  and  by  whom  they 
will  be  resolved.  In  addition,  classify  the  uncertainties  in 
accordance  with  "importance  of  resolution"  to  the  successful  com- 
pletion of  the  program,  and  potential  risk  to  the  overall  system 
performance  if- not  resolved. 

NOTE 

The  Importance  of  1.4  and  1.5  cannot  be  over- 
stressed. All  parameters  that  cannot  be  clearly 
defined  with  certainty  must  be  identified  as 
assiimptions  or  uncertainties. 
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2. 


MODULE  OPERATIONAL  SPECIFICATION 


2.1  Problem  Statement 

The  problem  statement  is  a nondetalled  explanation  of  the 
module  operational  function  or  requirement  that  will  be  satisfied 
by  the  computer  prograjn  developed  from  this  operational  specifica- 
tion. It  also  provides  program  design  personnel  with  a general 
insight  into  the  problem.  When  such  information  is  available,  it 
also  provides  attitudes  and  opinions  of  the  fleet  personnel  in  the 
operating  squadrons  who  have  contributed  input  to  be  used  in  the 
operational  specification. 

2.2  Computer  and  Peripheral  Equipment 
C ons ide  rat ions 

The  computer  program  for  a routine  will  be  written  in  the 
language  of  a particular  computer  operating  under  a particular 
executive  system.  The  peripheral  equipment  attached  or  available 
to  the  computer  must  be  uniquely  defined  so  that  manuals  and 
specifications  associated  with  the  equipment  and  software  can  be 
uniquely  referenced.  This  section  lists  these  reference 
requirements . 


2.2.1  Equipment  Description 

Within  this  section,  the  equipment  for  which  the  program  is 
being  prepared  is  identified  using  exact  nomenclature.  The  con- 
figuration of  the  equipment  is  identified  by  providing  the  modi- 
fication and  model  numbers  where  applicable.  The  modification  and 
model  numbers  are  Important,  since  the  programmer  may  refer  to 
equipment  manuals  or  other  documentation  as  sources  of  input  for 
the  preparation  of  the  computer  program.  Needless  to  say,  chaos 
would  exist  if  the  person  used  a Model  0 handbook  for  his  source 
of  capabilities,  limitations,  etc.,  when  preparing  a program  for 
the  Model  1 or  2 configuration  of  the  same  equipment. 

2.2.2  Executive  System 

The  computer  manufacturer  usually  supplies  an  executive  sys- 
tem with  his  computer  hardware.  This  is  a computer  progrsun  which 
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monitors  the  interfaces  between  different  parts  of  the  computer. 
Several  versions  of  an  executive  system  may  be  available  from  a 
computer  manufacturer.  Also,  revisions  of  the  various  versions 
will  probably  be  made.  It  is  very  important  for  the  programmer 
to  know  the  correct  name,  version,  and  revision  of  the  executive 
routine  for  which  he  will  be  programming.  Specify  any  changes  to 
the  executive  program  necessary  to  implement  specific  functional 
requirements  such  as  self-test,  reliability,  fault  isolation,  and 
degradation  control  demanded  by  operational  requirements. 

2.2.3  Compiler  and  Language 

This  section  defines  the  compiler  and  language  to  be  used, 
and  explains  the  features  of  the  compiler  that  will  be  used  for 
the  compilation.  Generally  speaking,  the  compiler  will  be 
completely  documented  by  a separate  manual  designed  for  this  pur- 
pose. When  this  is  the  case,  the  manual  must  be  referenced  by 
name.  Identifying  nvimber,  and  date  of  issue  in  effect  for  the 
procurement . 


2.2.4  Summary 

In  summary,  the  most  Important  consideration  of  Section  3 
is  configuration  identification  such  that  the  task  can  be  per- 
formed. There  are  two  problems  associated  with  configuration; 
producing  information  from  data  that  is  too  far  behind  or  ahead 
of  the  system  configuration.  This  would  be  especially  true  in 
the  operational  specifications  associated  with  early  configura- 
tions of  the  program.  Since  the  early  configurations  of  a program 
must  work  on  the  early  configurations  of  equipment,  the  most 
current  form  of  any  document  is  not  likely  to  be  compatible  with 
an  early  configuration  of  the  system.  Therefore,  it  is  imperative 
that  careful  consideration  be  given  in  Section  3 to  the  exact 
configuration  of  the  equipment  for  which  the  program  is  being 
prepared.  Also,  it  is  important  that  all  configurations  of  the 
required  data  listed  in  this  section  match  the  configurations 
under  consideration,  and  that  listed  configurations  neither  lag 
nor  precede  the  actual  system  configuration. 
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2.3  Referenced  Documents 

This  section  consists  of  a listing  of  the  names  and  numbers 
of  the  referenced  documents.  It  is  prepared  by  compiling  a list 
of  references  made  in  other  sections  of  the  operational  specifica- 
tion and  including  them  in  this  section.  As  such,  it  Includes 
all  of  the  documents  required  in  addition  to  the  Operational 
Specification  to  prepare  a computer  program  related  to  the  routine 
thereby  simplifying  the  gathering  of  the  data  required  for  a 
procurement  package.  For  each  document  listed,  specify  the  date, 
revision  number  and  originating  agency  in  addition  to  normal 
identifications . 

Many  of  the  parameters  surroxmdlng  the  equipment  and  f\inc- 
tions  that  provide  input  to  various  routines  are  under  control  of 
personnel  different  from  those  developing  the  particular  routine 
for  which  the  Operational  Specification  is  being  developed.  In 
this  case,  any  documents  providing  constraints  should  be  referenced 
rather  than  repeating  the  constraints  within  the  operational  speci- 
fication. An  example  would  be  the  data  rate  of  the  computer 
detector  or  the  word  format  of  a link  data  message.  These  types 
of  information  are  controlled  by  other  documents  and  could  cause 
confusion  and  repetition  if  listed.  When  the  data  link  message  is 
changed,  the  documentation  for  the  configuration  of  the  data  link 
message  will  be  revised  accordingly.  There  is,  however,  no  way 
to  know  that  the  configuration  of  this  data  link  message  is  pro- 
vided within  one  of  the  operational  specifications.  Thus,  there 
would  be  no  way  for  a person  to  ensure  that  all  possible  listings 
of  the  data  link  message  format  were  updated.  The  general  ground 
rule  for  referencing  or  incorporating  these  configurations  is  the 
source  of  control. 

2.4  Accuracies 

The  accuracy  required  by  a computer  program  should  be  part  of 
the  information  supplied  to  a programmer,  since  additional  program- 
ming effort  may  be  required  to  Increase  the  accuracy  of  a fixed- 
word  computer,  and  additional  storage  is  needed  to  extend  the 
accuracy  of  a character  computer. 


2.4.1  Input  Accuracy  Constraints 

In  this  paragraph,  the  input  accuracy  limitations  are  either 
specified  or  discussed  in  Section  4.  This  portion  of  the  Opera- 
tional Specification  should  be  a listing  of  the  accuracies  of  all 
input  data  or  commands  Incident  on  or  available  to  the  system. 

2.4.2  Output  Accuracy  Constraints 

Because  the  input  equipment  is  capable  of  providing  only  a 
specific  accuracy,  the  output  equipment  is  limited  to  functioning 
within  a certain  level  of  accuracy.  A parallel  constraint  exists 
because  it  would  not  be  logical  to  produce  any  more  accuracy  than 
the  output  device  is  capable  of  using.  The  reduced  requirement 
resulting  from  the  limited  capability  of  the  output  device  may  pro- 
vide a memory  saving  which  can  be  used  to  Increase  the  number  of 
tracks  handled,  or  it  might  improve  some  other  feature.  Further, 
algorithms  used  by  the  programmer  will  be  very  dependent  on  the 
accuracy  necessary. 

2.4.5  Required  Accuracies  of  the 
Computer  Program 

To  prevent  Injection  of  error  as  a result  of  the  reduced 
computer  accuracy,  some  computer  accuracy  parameters  must  be  defined. 
They  must  provide  for  more  accuracy  than  the  data  provided  by  the 
input  device  or  the  data  required  by  the  output  device.  The  degree 
of  accuracy  overlap  is  subject  to  negotiation  if  it  has  not  been 
defined  in  this  section.  In  that  case,  the  programming  accuracies 
that  were  actually  determined  and  used  after  the  completion  of 
initial  programming  should  be  extracted  and  located  in  this  portion 
of  the  operational  specification.  They  can  then  be  used  as  an  input 
for  future  procurements  of  modifications  to  this  particular  routine. 

2.5  External  Error 

This  section  is  concerned  prlruarlly  with  input  data  from 
operator  consoles;  however,  it  does  have  other  applications  to 
computer  programming.  When  it  is  possible  for  the  input  data  to 
be  applied  in  error,  there  must  be  some  provision  for  alerting  the 
operator  that  erroneous  data  is  being  provided  after  a specific 
number  of  attempts  have  been  made  by  the  computer  to  operate  on  the 


erroneous  data.  When  these  error  limits  are  applicable,  they 
should  be  provided  in  Section  5 of  the  Operational  Specification. 

If  no  error  limits  are  applicable  to  the  portion  of  the  computer 
program  associated  with  this  operational  specification,  this 
section  will  be  marked  "Not  Applicable." 

2.6  Word  Characteristics 

Word  characteristics  of  the  input  from  or  output  to  other 
routines  must  be  defined  even  when  the  program  is  an  initial  pro- 
curement. In  this  case,  a requirement  is  made  that  input  and 
output  words  be  compatible  with  the  other  operational  specifica- 
tions with  which  they  must  interface.  Any  reference  to  other 
operational  specifications  should  be  specific  rather  than  general. 
After  the  completion  of  the  initial  procurement,  the  word  config- 
uration that  was  used  should  be  obtained  from  the  computer  program 
documentation  and  inserted  in  the  operational  specification  to 
serve  as  a base  for  subsequent  procurement  of  revisions  to  the 
program. 

2.6.1  Input  Word  or  Switch 
Characteristics 

The  characteristics  of  the  input  word  from  another  routine 
in  the  program  or  the  signal  characteristic  of  an  output  of  a 
switch  at  the  console  are  described  in  this  paragraph.  For  switch 
input,  the  point  of  computer  access  by  the  program,  the  voltage 
level  or  the  bit  representation  of  the  ON  or  OFF  position,  or  the 
setting  of  the  switch  must  be  provided.  The  input  word  must  be 
defined  by  name  and  the  work  configuration  must  be  provided. 

When  the  procurement  is  for  a revision,  and  if  the  computer 
for  which  the  operational  specification  is  being  prepared  is  a 
special-purpose  computer  that  uses  a drum  memory,  the  drum  loca- 
tion and  word  configuration  must  be  provided.  If  the  computer  for 
which  the  operational  specification  is  being  prepared  is  a general- 
purpose  machine,  the  identifying  name  by  which  the  word  can  be 
called  from  memory,  and  the  word  configuration,  must  be  provided, 
so  that  masking  and  shifting  can  be  accomplished,  when  necessary. 
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2.6.2  Output  Word  or  Display 
Characteristics" 

The  same  requirements  surround  the  output  word  resulting 
from  the  routine.  If  the  output  Is  a display  symbol  or  light,  the 
characteristic  of  the  symbol  or  proper  nomenclature  of  the  light 
should  be  provided  at  this  point. 

If  the  procurement  Is  for  a program  revision  and  If  the  word 
Is  to  be  stored  on  a special-purpose  computer  with  a driun  memory, 
the  drum  location  and  word  bit  configuration  must  be  provided. 

If  the  output  word  Is  being  developed  for  a general-purpose 
computer,  the  calling  name  and  the  bit  configuration  of  the  word 
must  be  provided. 

2.7  Memory  Requirements 

Since  the  core  memory  must  be  allocated  among  the  various 
routines  to  be  operating  within  the  framework  of  the  whole  program, 
I specific  memory  allocations  must  be  provided.  Here  again,  the 

j initial  and  subsequent  procurements  must  be  analyzed.  In  the 

I initial  procurement,  the  requirement  for  memory  may  only  be  the 

j constraint  that  the  total  memory  allocation  of  the  program  does 

I not  exceed  the  total  memory  capability  of  the  machine.  After  tne 

j completion  of  the  memory  allocations  on  the  initial  procurement, 

I the  memory  allotted  plus  a proportionate  division  of  the  remaining 

j memory  must  be  allocated  to  the  routine  and  specified  in  the 

j operational  specification.  Subsequent  procurements  can  then  be 

initiated  within  the  framework  of  the  memory  capability  of  the 
computer  program. 

2.8  Program  Time  Allocations 

In  this  section,  the  time  required  to  run  the  routine  covered 
by  the  operational  specifications  must  be  provided.  All  of  the 
considerations  of  the  initial  and  subsequent  procurement  discussed 
' under  Memory  Requirements  apply  equally  to  the  definition  of  pro- 

gram run  time  allocations. 

Timing  constraints  imposed  by  real  time  operation  of  other 
portions  of  the  program  or  equipments  associated  with  the  program 
must  also  be  provided. 
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2.9  Specific  Requirements 

The  specific  requirements  of  each  particular  routine  are 
provided  In  this  section.  These  are  the  requirements  that  the 
routine  should  meet  to  accomplish  the  Initial  objective.  An 
example  of  these  types  of  requirements  for  tracking  would  be  the 
establishment  of,  and  the  ground  rules  surrounding,  the  determina- 
tion that  a target  Is  an  air  target  rather  than  a surface 
target,  etc. 

2.10  Testing  Requirements 

As  established  In  the  specification  for  computer  programming, 
logic,  simulation,  and  operational  testing  are  available  for  each 
of  the  routines  developed  In  a procurement.  Logic  testing  literally 
tests  that  the  program  will  run  as  designed.  Simulation  testing 
establishes  that  the  program  will  meet  the  operational  requirements 
in  a simulated  environment,  and  operational  testing  is  conducted  to 
evaluate  the  program  under  actual  operational  conditions  and 
situations . 

I 

Surrounding  such  tests  are  the  parameter  of  the  initial  and 
subsequent  procurements.  During  an  initial  procurement,  the  various 
testing  routines  probably  will  have  to  be  developed  for  each  of  the 
phases  of  the  testing.  In  subsequent  procurements,  however,  the 
initial  logic  and  simulation  testing  routines  developed  for  the 
Initial  procurement  may  be  adequate  to  verify  the  performance  of 
the  routine  during  the  subsequent  revision  procurement.  When  this 
is  so,  the  routines  to  be  used  to  verify  the  program  as  designed 
should  be  referenced  by  name  and  configuration  nvimber.  For  such 
cases,  the  configuration  constraints  discussed  in  Section  5 would 
apply. 
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